home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9028 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: io.com!not-for-mail
  2. From: jamshid@io.com (Jamshid Afshar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ & macros
  5. Date: 27 Feb 1996 21:11:20 -0600
  6. Organization: Illuminati Online, Austin, Texas, USA
  7. Message-ID: <4h0h4o$7a3@xanadu.io.com>
  8. References: <DLBxoH.GLw@ariel.cs.yorku.ca> <4eun5f$50c@cloner4.netcom.com> <4gg06d$401m@news-s01.ny.us.ibm.net> <4gioa2$nsb@sun152.spd.dsccc.com>
  9. NNTP-Posting-Host: xanadu.io.com
  10.  
  11. In article <4gioa2$nsb@sun152.spd.dsccc.com>,
  12. Kevin Cline <kcline@sun152.spd.dsccc.com> wrote:
  13. >[...]
  14. >Using macros to define functions is a very bad idea.  Use inline functions
  15. >instead.  This allows the compiler to decide whether inlining the code
  16. >is faster than a function call.  The compiler knows more about this than
  17. >the programmer.  Also, inline functions calls are typesafe.
  18. >
  19. >Macros should only be used for text-processing tricks that improve
  20. >code maintainability, e.g.
  21.  
  22. Some of my favorite Stroustrup quotes are in CPL2 4.7 Macros. "first
  23. rule is: Don't use them if you don't have to.  It's been observed that
  24. almost every macro demonstrates a flaw in the programming language, in
  25. the program, or in the programmer. [...] expect inferior service from
  26. tools such as debuggers, cross reference tools, and profilers. [...]
  27. If you must [...] try not to be too clever."  And my favorite, "Using
  28. macros you design your own private language; it will most likely be
  29. incomprehensible to others."
  30.  
  31. >    #define FRUIT_LIST \
  32. >        FRUIT(apple), \
  33. >        FRUIT(orange), \
  34. >        FRUIT(pear)
  35. >
  36. >    #define FRUIT(t) t
  37. >    typedef enum { ITEM_LIST } Fruit;
  38. >    #undef FRUIT
  39. >
  40. >    // #t produces a quoted string 
  41. >    #define FRUIT(t) #t
  42. >    static const char* const FruitNameTable[] = { ITEM_LIST };
  43. >    #undef ITEM
  44. >
  45. >When the list gets long, techniques like this can be useful for
  46. >reducing redundancies in source code.  I find that as soon
  47. >as I have to specify the same thing twice, and the compiler is unable
  48. >to make sure they match, they won't. 
  49.  
  50. Is the above convenience worth the extra lines of code and comments?
  51. Is it worth the extra time future maintainers are going to have to
  52. take figuring out this scheme and verifying in their mind that it does
  53. what's expected?  Wouldn't it take less time to just copy&paste the
  54. enumerator list and use your editor's keystroke record and playback to
  55. safely change the items to string literals?  Of course, different
  56. programmers will have different opinions on this, but I wouldn't want
  57. to use or maintain macro tricks like the above (though I've seen much
  58. worse -- the "#define GLOBAL extern" trick is especially silly,
  59. especially when people get fancy and try to add a INIT(value) macro).
  60.  
  61. Jamshid Afshar
  62. jamshid@io.com
  63.  
  64.